Volume 1

Issue 3

September 2004

Best Practices Best Practices for Selecting a CMS James Robertson Step Two Designs jamesr@steptwo.com.au Selecting the most effective content management system (CMS) is recognized as a crucial first step for a content management project, yet many organizations struggle with this process. This article draws upon industry experiences to outline the best practice approaches to selecting a CMS, thereby providing the foundation for a successful CMS implementation. Content management marketplace The first step in selecting a content management system is to recognize that CMS products in the marketplace are extremely diverse, with every product having a unique vision, architectural design or strategic direction. This means that each product has a strong mix of both strengths and weaknesses; there is no one `best product' in the marketplace. The challenge therefore is to identify the product that is the best fit to your unique business requirements. Out of the hundreds of products in the marketplace, perhaps less than a dozen will be suitable in any specific situation, putting further weight on the selection and evaluation process. Requirements-based selection Best practice recommends a requirements-focused [1] selection process that starts by identifying the specific business requirements for the CMS. This involves consulting all stakeholders, reviewing existing systems, and aligning with business strategy. The result is a comprehensive set of requirements, driven by business needs (not technology issues). Among these, your key requirements are clearly identified, along with the "nice to haves". For example, technology-focused requirements may specify that the CMS should "store content in multiple repositories". While this may be meaningful to the writer of the requirement, it often means little to others (including the vendors), and gives no real context for the business need. Instead, the business requirement may be to "allow authors located in offices world-wide to easily and efficiently write content for the centralized corporate intranet". This gives a clear description of the business need, and it allows a range of technology solutions to be proposed by the vendors. Once captured in this form, content management systems can then be evaluated against these business requirements, to identify the most suitable product. This resolves the difficulty of comparing very different products against each other, as each product is assessed against your business requirements alone. Focus on how, not what When evaluating products, you need to focus on the how, not the what. At a high level, all content management systems have the same basic capabilities (authoring, workflow, version control, publishing, etc.). Beyond this, it is how these features work in practice that will make the difference between a product that is suitable for your needs, and one that won't work (or will require extensive customization). The classic example of this is integration with other systems. It is clearly not sufficient to simply say "the CMS must integrate with existing systems" (although this appears all too often in tenders). Instead, the tender must outline which specific systems the CMS will be connected to, how these connections will be made, what information will be exchanged, and how often. The selection process must therefore be designed to give you the confidence that the way the CMS is designed is a good match to your working practices and environment. In practice, this is best done by: describing specific needs in the tender, providing details about the organizational environment requiring the vendor to provide descriptive answers, rather than "complies" or "does not comply" asking vendors to include examples and screenshots in their responses It must also be recognized, however, that some aspects of the content management system cannot be meaningfully evaluated solely on written responses to the tender. For example, the usability (ease of use) of a CMS can only be assessed by examining the system in operation (such as during the vendor demonstrations). Capturing business requirements The primary purpose of the requirements (and the tender or RFP documents as a whole) is to clearly communicate your needs, to both vendors and internal stakeholders. This means writing the requirements in a form that can be easily understood by all readers, and providing sufficient context about the underlying business needs and environment. Using a narrative format Traditionally, requirements have been documented in a very formal, highly-technical format. While the aim was to ensure that all the requirements were captured in sufficient detail, tenders in this style typically generated more confusion than clarity (for both stakeholders and vendors). Instead, requirements should be written in a narrative format [2]. For example, the requirement "the CMS must provide web-based admin tools" is much better captured as follows: All day-to-day administration of the CMS will be conducted by the web team. There are limited technical skills in-house, so the CMS should provide easy to use GUI interfaces for administrative tasks. It is expected that the site designs are unlikely to change frequently, so the capability to maintain stylesheets and templates in-house is less important. Using this format provides much greater context to the requirements, and in practice is actually easier to evaluate than the over-formalized format generally used. Focusing on key selection criteria Many tenders contain hundreds of requirements, with little (or no) information indicating the relative importance of each requirement. Beyond making it harder and more time-consuming to evaluate tender responses, this over-specification of requirements can force the selection of a CMS that is larger than is actually required. In practice, there is a very real cost to be paid for each requirement specified, in terms of cost, complexity, and impact on usability. For this reason, it is critical to identify the key selection criteria for the content management systems. The key selection criteria are those requirements that absolutely must be met by the CMS, if the project is to be successful. There will be typically less than a dozen of these for most projects, and they must be clearly identified and communicated in the tender. Avoiding over-emphasis of technical details The final challenge is to avoid over-emphasizing technical details [3] in the tender documents. While there will be some important technical constraints and considerations, experience has shown that the final selection of the CMS is more likely to be based on the business (rather than technical) requirements. Developing the tender Once the business requirements have been developed, assemble them into a tender (or RFP) document, suitable to be given to prospective vendors. This must provide sufficient background and context to allow the vendor to easily interpret the specific requirements listed. Using scenarios Scenarios (narrative descriptions; stories) should then be used to explore specific issues, and to document how the CMS will work in practice. In the context of a content management system project, scenarios are a very effective way of documenting key CMS requirements, and they complement the list of requirements in the tender. The scenarios bring together a range of requirements, putting them into a sequence that matches how users will typically work with the CMS. When documented in this form, a much clearer (and richer) picture is provided of the particular needs of the authors and publishers. For example, the following is a simple scenario that captures common authoring needs: Robert is an author who has the responsibility for maintaining some sections of the website. A new press release needs to be created for the site. Robert creates a new page in the CMS, indicating that it will be a press release. This provides a number of specific fields to be filled in (such as title, release date and contact details for the press officer), as well as an area for the body of the press release (as formatted text). Robert then specifies the metadata for the page (this has been made very simple by the CMS, which has defaulted many of the values). He also indicates that the press release should be released at 9 AM tomorrow morning, in sync with when the press release will go to the media. Having completed the mandatory metadata for the press release, Robert forwards it to his manager Lyn for her review. Lyn is happy with the release, and therefore forwards it to Sandra (one of the web team) to do a final quality check, before approving it for release. Vendor demonstrations and beyond The scenarios then form the basis for the vendor demonstrations, thereby ensuring that the sessions are more than just a generic `sales pitch' from the vendors. The scenarios also allow the demonstrations to be directly compared, as well as making it easier to evaluate the products against the business requirements. Beyond the vendor demonstrations, you should then take whatever additional steps (contacting reference sites, conducting trial periods, etc.) that are necessary to build confidence that the selected product is going to provide the best (and most cost-effective) solution for your specific needs. Guidelines for the selection process Beyond the approaches discussed above, consider the following when selecting a CMS: specify business goals and outcomes build internal content management knowledge ensure sufficient time is allocated to the selection process consider a wide range of products in the marketplace focus on mitigating project risk focus on usability and simplicity See the AGIMO Better Practice Checklist [4] on selecting a CMS for more on these guidelines. Further resources Organizations looking for further resources on selecting a content management system should consider obtaining the Content Management Requirements Toolkit [5]. This contains a comprehensive set of pre-developed CMS requirements, as well as supporting details on the selection process (including instructions on how to write scenarios). The CMS Report [6] also provides valuable information for organizations looking to purchase a content management system, and it includes reviews on major CMS products (both commercial and open-source) along with an exploration of many content management issues and approaches. Summary Selecting a content management system out of the hundreds in the marketplace is not easy. By taking a requirements-based approach, you can identify a product that is a close fit to the unique business needs and environment of your organization. Capturing requirements in a narrative format, using scenarios, and managing vendor demonstrations will then help you to explore, in-depth, prospective products, and to mitigate the risk of selecting the wrong product. References [1] A better approach: requirements-focused CMS selection, www.steptwo.com.au/papers/cmb_requirements [2] Using narrative in a CMS tender, www.steptwo.com.au/papers/cmb_narrativetender [3] Specifying technology in a CMS tender, www.steptwo.com.au/papers/cmb_tendertech [4] Selecting a Content Management System, www.agimo.gov.au/practice/delivery/checklists/select_cms [5] Content Management Requirements Toolkit, www.steptwo.com.au/products/toolkit [6] The CMS Report, www.cmswatch.com/TheCMSReport